home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 573 / text0000.txt < prev   
Encoding:
Text File  |  1996-08-05  |  4.0 KB  |  101 lines
  1.  
  2. I have just read the your answer to my previous posting. Thanks to everyone
  3. for the answers.
  4. Actually my c2p are processor-only converters because I dont understand
  5. enough about blitter-coding. Besides I am mainly interested in
  6. 8bpl-converters for my 3d-routines. The original c2p-routines are from
  7. aminet (I think fastc2p.lha )
  8. My c2p get a pointer to the chunkydata, one to the (continious) bitplane(s)
  9. and the plsize. And of may be an comparebuffer. The 3d-routines know
  10. nothing about the display-enviroment. They simple get the x,y-size, the
  11. number of colours and 2 functionpointers. One to the db-switchroutine and
  12. one the the c2p. So its no problem to support gfx-cards.
  13. I will not send followups to all articles but instead I put all my new
  14. questions into this posting:
  15.  
  16. - Stephan Schaem (sschaem@teleport.com) <4cjl2o$4im@maureen.teleport.com>
  17. >:   - are there any very fast c2p which use a comparebuffer ?
  18. >
  19. > depand on the aplication I guess... The amiga mac emulator ShapwShifter
  20. > has a range of driver that use Delta/checksum/mmu buffer in conjunction
  21. > with the plannar/chunky buffer.
  22.  
  23. Could you give me a hint what a Delta/checksum/mmu buffer is ?
  24. ( I use a comparebuffer which check if a block of 8 pixels have changed. If
  25. yes then the comparebuffer is updated and the converter starts. If not I
  26. simply step to the next block)
  27.  
  28.  
  29. - Juergen "Rally" Fischer (fischerj@Informatik.TU-Muenchen.DE)
  30. <4cjmsk$9aa@sunsystem5.informatik.tu-muenchen.de>
  31. >:     (I have heard this sometimes  in this group)
  32. >:     and what are his adventages/disadvantages ?
  33. >:   - are there any very fast c2p which use a comparebuffer ?
  34. >yes, AFAIK Peter McGavin got most experience data on this.
  35. >AFAIK the routines get very fast when the soure to convert doesn't
  36. >change much.
  37.  
  38. Where could I get this routines ? (could you mail me the source?)
  39.  
  40.  
  41. - Jyrki Saarinen (jsaarinen@kone.fipnet.fi) <38231876@kone.fipnet.fi>
  42. >> Are there really fast 6 bitplane c2p-converter ?
  43. >> My actual approachs are (50Mhz 030, OS-conform (except screens of
  44. >> gfxcards), 320x256)
  45. >>   8bpls : 45ms
  46. >>   6bpls : 43ms
  47. >>   4bpls : 30ms
  48. >> These c2p-converter(s) use LONG-writes to CHIPmem.
  49. >
  50. >What routine this is? I guess 030/50 should be able
  51. >o get c2p free -->รก320x256x8 screen should be about 20ms.
  52. >This could be perhaps achieved by doing three passes
  53. >with CPU and the last one with the blitter.
  54.  
  55. Sounds good could you post or mail some asm-source ? I would prefer a
  56. cpu-only-solution.
  57.  
  58.  
  59. - Andrew Bennett (ben@gauss.demon.co.uk) <30ef4f99@gauss.demon.co.uk>
  60. > Assuming that you still have a screenful of planar data from the last
  61. >conversion,it's very likely that a lot of the new planar data you write
  62. >will be
  63. >identical to the old copy and thus doesn't need to be overwritten with the
  64. >same
  65. >data!! (Depending on the type of graphics used and the amount of change
  66. >per
  67. >frame...)
  68. >
  69. > The end result is a c2p routine which takes a variable amount of time to
  70. >do
  71. >the conversion,but may well be faster.
  72. >
  73. >eg: Assuming that the first four pixels are colours 12,13,220,114. On the
  74. >next
  75. >pass let's say they are now 15,12,223,116.
  76. >
  77. > If you eor the old set with the new set,and re-order the data into
  78. >planar,you'll find that only planes 1 & 2 have actually changed...  So you
  79. >can
  80. >save 6 chip writes and a fair bit of manipulation,but at the the expense
  81. >of
  82. >reading twice as much data from (hopefully) fast memory.
  83.  
  84. Have you any expierences (I mean working code) with this? I suppose that
  85. this only give advantages if not more than 4 planes have changed. In this
  86. case you could use a changed 4bpl converter which is a lot faster. But if
  87. you do so, the code became really big and dont fit into the cache. The
  88. speed penality for this will probably destroy all advantages.(I think so)
  89.  
  90.  
  91.  
  92. Also someone wrote that you could do 12 or 13 instructions during chip
  93. write. Is there somewhere (in aminet) a time-table on this ?
  94. I found a c2p-converter which use selfmodifying code. This one copy himself
  95. to a quadword-align memory-position. Does this give any advantages ? (I
  96. think a 8bpl c2p is small enough to fit into the cache)
  97.  
  98.  
  99. Cia,
  100. Sven.
  101.